Codecov Report

Merging #372 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #372   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           9      9           
  Lines         830    834    +4     
  Branches      174    175    +1     
=====================================
+ Hits          830    834    +4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 57817b2...a5c05df. Read the comment docs.

First thought:

why aren't we supporting this:

@attr.s
class C:
    a = attr.ib()
    b = attr.ib()

    @attr.validator
    def _validate(self):
        if self.a > self.b:
            raise ValueError()

Then I went and read the linked issue.

I think runtime type validation is a cool feature that we should definitely support. However the interface of the proposed solution is ugly to me. If you are an advanced attrs user, and you want to extend attrs, you don't actually need this functionality - wrap attr.s or place a class decorator underneath that would wrap an existing attrs_post_init or add a new one if none found, and do your logic in there.

Hm that seems a bit complicated to me. The idea is that you can write a reusable validator that looks at __annotations__ and uses one of the many available type checkers. That sounds like something that should be possible without wrapping @attr.s?

First of all, I'm not going to stop you merging this in, just thinking out loud. :)

We already have a mechanism for executing code after init is done, it's the post_init.

What if you want an additional instance validator after or before typechecking?

Also note:

@attr.s(validator=typecheck)
class C:
    a: int = attr.ib()

In this scenario, typecheck will have to be a generic function, right? What I mean by this is, all instances will share a single function, and this function will probably call attr.fields and iterate over them. If I was doing this, I would want to eval a specialized function to avoid the overhead. And in that case, you need to either wrap attr.s or do your own class decorator. Since I appreciate code aethethics, I would do (hypothetically):

@typechecked.attr.s
class C:
    a: int = attr.ib()

Well, thinking is what I’m (not – but I totally would) paying you for, so please keep doing that. ;)

I guess it’s true that it might get too slow to do it dynamically. 🤔

Maybe you should hopp over to #301 and make some suggestions (after reviewing my PRs natch), I’m gonna close this for now.